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METHODE D" AUTH ENTI RC ATI ON D'APPUCATIONS 

La presente invention conceme le domaine des reseaux mobiles appeles aussi 
reseaux cellulaires. Elle conceme plus particulidrement la gestion de la securite 
d'applications mise en aeuvre avec un module de securite associ6 £ un equipement 
5 mobile de telephonic mobile. 

Le module de securite d'un telephone mobile ou portable est connu sous 
I'appellation "carte SIM" (Subscriber Identity Module) constituant l'6lement central 
de la securite de ces telephones. L'operateur de tdldphonie Introduit, a la fabrication 
et/ou lors d'une phase de personnalisation, un numero appele IMSI (International 

10 Mobile Subscriber Identification) servant & identifier d'une manldre sOre et unique 
chaque abonne desirant se connecter sur un rdseau mobile. Chaque telephone 
mobile, appelg Equipement mobile ci-aprds, est identifie physiquement par un 
numero stock6 dans une m6moire non volatile de l'§quipement mobile. Ce numero, 
appele IMEI, (International Mobile Equipment Identifier) contient une identification 

15 du type d'equipement mobile et un numero de serie servant a identifier de manure 
unique un equipement mobile donne sur un reseau du type GSM (Global System for 
Mobile communications), GPRS (General Packet Radio System) ou UMTS 
(Universal Mobile Telecommunications System). De plus, un 6quipement mobile est 
caract6ris6 par une version de logiciel SVN (Software Version Number) indiquant 

20 I'etat de mise a jour du logiciel de base installe sur l'6quipement mobile. La 
combinaison de ridentification du type et du numero de serie de T6quipement 
mobile avec la version de logiciel (SVN) donne une nouvelle identification, appeI6e 
IMEISV (International Mobile Equipment Identifier and Software Version Number). 
Le meme concept d'identification s'applique dgalement au WLAN (Wireless LAN) ou 

25 au cable TV bidirectionnel. L'identifiant physique peut etre une adresse MAC (Media 
Access Control) qui correspond £ Tadresse unique identifiant la configuration du 
materiel d'un utilisateur sur un reseau IP (Internet Protocol) et la version de logiciel 
peut etre transmise par des protocoles de couche sup6rieure bases sur IP. 

Les normes ETSI ("European Telecommunications Standards Institute"), d6finissent 
30 une station mobile (MS, mobile station) composee d'un equipement mobile (ME, 
mobile equipment) et d'un module d'abonne (SIM, subscriber identity module). Ce 
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module d'abonne est en general amovible c'est-^-dire qu'il peut etre sort retlr6 soit 
transfer^ d'un equipement mobile d un autre. 

Lors de la mise en service d'un Equipement mobile, plus particulierement lors de sa 
connexion au reseau d'un operateur, des informations comprenant les donn6es 
5 d'identification sont echang6es entre I'equipement mobile et le centre de gestion de 
I'operateur qui autorise ou non son utilisation. Actuellement un equipement mobile 
offre a i'utilisateur, en plus de sa fonction usuelle d'etablissement de conversations 
telephoniques par le biais d'un acces a un reseau mobile, ('utilisation de nombreux 
autres services supplementaires a valeur ajoutee tels que la consultation de 
10 diverses informations, les operations bancaires a distance, le commerce 
electronique, I'acces a du contenu multimedia, etc. Ces services 6volues 
necessitent un niveau de securite de plus en plus eleve afin de pr6munir les 
utilisateurs contre les fraudes eventuelles causees par des tiers cherchant a 
exploiter des failles de s6curit6 qui peuvent apparaTtre sur les 6quipements mobiles. 

15 Une verification devient done n6cessaire au moins a deux niveaux: d'une part au 
niveau de Tequipement mobile lui-meme et d'autre part a celui des applications 
logicielles permettant le fonctionnement des diff6rents services proposes par 
I'operateur ou des parties tierces. Ces applications sont en general tel6chargees 
depuis le serveur d'un fournisseur d'applications, ce qui implique la n6cessite de 

20 verifier ce tel&chargement. H s'agit done de garantir que le module d'abonne ne 
fournit des informations qu'd des applications autoris^es une fbis que ce module a 
6t6 reconnu par le serveur de contrdle comme pouvant fonctionner avec 
r^quipement mobile dans lequel il est insere. 

Le module d'abonne peut contenir des informations confidentielles tels qu'un 
25 num^ro de compte bancaire ou un mot de passe. Une application fonctionnant sur 
l'6quipement mobile sera en charge d'utiliser ces donnees personnelles afin de 
fournir le service attendu. Neanmoins, une application pourrait detourner ces 
donnees personnelles a d'autres fins que le dialogue avec le fournisseur 
d'application conceme. II peut en resulter un prejudice important pour le propri6taire 
30 du module d'abonng. 
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Ces applications ex6cut6es dans I'dqulpement mobile utilisent des ressources 
disponibles dans le module d'abonne. Par ressources, on entend diverses fonctions 
et donn6es n6cessaires au bon fonctionnement d'une application. Certaines de ces 
ressources peuvent etre communes a plusieurs applications, notamment les 
fonctions Ii6es d la s6curit6. Le module d'abonn6 peut ainsi bloquer ou aft6rer le 
fonctionnement de certaines applications pour lesquelles les conditions de sScurite 
etablies par I'operateur et/ou les foumisseurs d'applications ne sont pas respect6es 
dans I'equipement mobile en question ou les droits de Putilisateur de l'6quipement 
mobile sont insuffisants. 

Le document FR2831362 decrit un proc€de de transaction s£curls€e entre un 
telephone mobile muni d'une carte SIM et un serveur duplications. Le but de ce 
precede est de proteger des droits lies a I'utilisation d'applications telechargees 
depuis le serveur au moyen de la carte SIM. 

Selon ce proc6d6, un lien de confiance est d'abord 6tabli entre le serveur et la carte 
SIM par I'echange s6curise de cles publiques, puis un achat d'une application est 
effectug par la transmission d'un fichier de demande par I'equipement mobile au 
serveur. Celui-ci encrypte parOellement ou entierement Tapplication et transmet a 
I'equipement mobile un cryptogramme forme par la cle d'encryption et une 
commando, le tout crypto avec une cl6 publique connue de la carte SIM. A la 
reception par I'equipement mobile, ce cryptogramme est d£crypt6 et la c!6 stock6e 
dans la carte SIM. L'exgcution de la commando entraTne le t6I6chargement dans 
I'equipement mobile de ('application partiellement ou entierement encrypt^e par le 
serveur. Une fois chargee, I'application est decryptee par la c!6 stock6e dans la 
carte SIM puis installee dans I'equipement mobile. 

Selon ce procede, les droits d'utiliser I'application dans I'equipement mobile sont 
proteges du fait du lien de confiance etabli initialement entre I'equipement et le 
serveur et precedant la transaction. Le role joue par le serveur se concentre ici 
plutot dans la gestion des droits ou DRM (Digital Rights Management) des 
utilisateurs d'une application dans un equipement mobile. La solution developpee ci- 
apres est orientee plutot vers ia gestion des risques (Risk Management) pris en 
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compte par I'operateur, le foumisseur d'application ou rutilisateur par rapport d une 
application. 

Le but de la presente invention est de proposer une methode d'authentification de 
ou des applications dans un gquipement mobile tant lors de leur t6!6chargement 
5 que lors de leur execution. II s'agit de limiter les risques lies au fait qu'un module 
d'abonne soit utilise a mauvais escient soit par des applications ne remplissant pas 
certains criteres de securite, soit par des equipements mobiles ne remplissant pas 
certains criteres de securite preetablis. 

Un autre but est de proteger rutilisateur de I'equipement mobile ainsi que les 
10 foumisseurs duplications concernes centre les abus resultants de I'usage 
d'applications non autorisees. 

Ces buts sont atteints par une methode d'authentification d'au moins une application 
fonctionnant dans un 6quipement connects par un rdseau d un serveur de contrSle, 
ledit equipement etant localement connecte d un module de s6curite, ladite 
1 5 application est chargee et/ou executee au moyen d'un envinonnement d'ex6cution 
d'applications de I'equipement et utilise des ressources stockees dans le module de 
securite, comprenant les etapes preliminaires suivantes: 

- r6ception de donnges comprenant au moins Tidentifiant de l'6quipement et 
I'identifiant du module de securite, via le r6seau, par le serveur de controle, 

20 - analyse et verification par le serveur de controle desdites donn6es, 

- generation d'un cryptogramme comprenant une empreinte de I'application, des 
donndes identrfiant I'equipement et le module de securite et des instructions 
destinees audit module, 

- transmission dudit cryptogramme, via le reseau et I'equipement, au module de 
25 securite, 

- verification de I'application en com pa rant I'empreinte extrarte du cryptogramme 
regu avec une empreinte determinee par le module de securite, 

ladite mdthode est caract6ris6e en ce que, lors de rinitialfsatlon et/ou de I'activation 
de I'application, le module de s 6c u rite execute les instructions extraites du 
30 cryptogramme et lib&re, respectivement bloque I'acc&s £ certaines ressources dudit 
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module de s6curit6 en fonction du rgsultat de la verification propre a cette 
application effectuee prealablement. 

Les ressources du module de securite sont bloquees ou liberees de maniere ciblee, 
ceci dans le but de rendre certaines applications utilisables ou non. On ne bloque 
pas ou libere pas directement des applications de I'equipement mobile: on agit de 
maniere indirecte sur les applications, c'est-a-dire que I'effet de biocage ou de 
liberation va se manifester uniquement lorsque I'equipement mobile essaiera 
d'executer ces applications. 

Cette methode s'applique de preference au r§seau mobile. Par consequent, 
I'equipement est, par exemple, un equipement de telephonie mobile et le module de 
securite un module d'abonne ou carte SIM. Cet ensemble se connecte a un r6seau 
mobile du type GSM (Global System for Mobile communications), GPRS (General 
Packet Radio Service), UMTS (Universal Mobile Telecommunications System) ou 
autre, gere par un serveur de controle d'un operateur. Des applications logicielles 
sont installees dans I'equipement mobile et configurees de maniere a utiliser des 
ressources (donnees ou fonctions) presentes dans le module d'abonne. Elles ne 
peuvent done dtre utilisdes dans leur integralite seutement si les conditions de 
securit6s sont satisfaites selon des criteres preetablis par 1'operateur et/ou le 
foumlsseur d'applications. Cette verification des criteres est d la charge du serveur 
de controle. (-'application, suite aux instructions envoy&es par le serveur de 
controle, est finalement a la charge du module de sdcuritd qui peut laisser libre ou 
bloquer Tacces a des ressources necessaires au bon fonctionnement d'une 
application installee dans I'equipement mobile. 

Les donnees de ces ressources peuvent comprendre des informations tels que 
num6ro de comptes, des programmes (sous forme de code pouvant etre installs 
dans I'equipement mobile), des cles d'encryption/decryption, des droits d'acces a du 
contenu, etc. 

Les fonctions de ces ressources peuvent comprendre des algorithmes 
cryptographiques, des processus de verification, des processus de generation de 
signatures digitales, des processus d'encryptage, des processus d'authentfflcation, 
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des processus de validation de donndes, des processus de contrdle d'acc&s, des 
processus de sauvegarde de donnees, des processus de paiement etc. 

La rnethode selon ('invention est bas6e sur le fart qu'a une application on associe un 
cryptogramme qui conditionne ('utilisation de I'application sur un dquipement mobile 
5 connects a un reseau. 

A la difference du proc6de decrit dans le document FR2831362, I'encryption 
partielle ou entiere de Implication , avant telechargement dans l'6quipement mobile, 
n'est pas n6cessaire. En effet, selon la rnethode de I'invention, la liaison entre le 
serveur et le module de securite (ou module d'abonne) sert a controler de maniere 
10 optirnale ses ressources et a decider leur mise en service ou non par rapport aux 
applications executees dans I'equipement mobile. La commande regue du serveur, 
dans le proc6d6 du document cite, permet de controler I'utilisation de I'application 
installee dans I'equipement mobile, tandis que dans la presente rnethode, elle 
permet d'activer ou desactiver des ressources du module de securite. 

15 Par exemple, lorsque des ressources sont d§sactiv6es, I'application fonctlonnera 
d'une fagon "minimale" laissant un nombre reduit de possibilrtes & I'utilisateur. Dans 
un exemple de realisation, cette reduction peut porter sur le montant maximum 
autorise pour I'achat de services et de plus, ces services ne pourraient etre obtenus 
que clans un lieu donne (centre commercial, stade, gare, aeroport, etc.) 

20 Dans un premier mode de realisation, le cryptogramme est transmis au module 
d'abonne pendant le chargement de I'application. Dans un second mode de 
realisation, c'est ('application qui va chercher le cryptogramme sur le serveur de 
contrdle lors de sa premiere utilisation. 

La rnethode d'authentification selon I'invention s'applique egalement lors de 
25 ('execution d'une application par I'equipement mobile, ce qui permet de s'assurer, a 
Paide du module d'abonne, que cette application est autorisee a acceder certaines 
ressources (donnees ou fonctions) contenues dans ledit module d'abonne. En 
particulier, le module d'abonne peut verifier regulierement le cryptogramme attache 
£ uno application au cours de I'execution de ladite application. 
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Par exemple, I'insertion d'un module d'abonne d'un utilisateur dans un autre 
equipement mobile influencera le fonctionnement de certaines applications sans 
empecher i'etablissement de communications t6l6phoniques classiques. Cette 
barriere agit en quelque sorte comme un filtre visant d 6liminer des equipements 
5 mobiles non autorises ou encore des applications provenant de sources non 
agr66es par I'operateur ou un fournisseurd'application partenaire. 

Une modification de ('application par un tiers est egalement detectee par le module 
d'abonne qui refusera d'ex§cuter certaines commandes regues entratnant ainsi le 
blocage ou des limitations de I'execution de ('application. 

10 Le serveur de controle joue done un role essentiel en gdrant les elements de 
confiance ou de securite Ii6s d I'ensemble equipement mobile/module d'abonne. II 
interprdte les donn6es qui lui sont transmlses par l'6quipement mobile afin de 
controler ou limiter ('utilisation duplications grace aux ressources (donn£es ou 
fonctions) stockees dans le module d'abonn6. 

15 Le serveur recevant les informations d'identite d'un equipement mobile et de son 
module d'abonne et comprenant les identifiants IMEISV et I'IMSI decide, seion 
certains crrteres, si une nouvelie instruction doit etre envoyee au module d'abonn§ 
pour red6finir un nouveau profil de protection definissant les ressources du module 
d'abonne pouvant etre utilisees par les applications executees dans I'equipement 

20 mobile. Les criteres peuvent se r6f6rer, par exemple, d la mise d jour de la version 
de logiciel instance sur I'equipement mobile, au t£l6chargement de nouvelles 
applications sur I'equipement mobile, d la p6riode de mise a jour du profil de 
protection, au nombre de connexions au reseau, a la technologie utilisee pour 
i'acces au reseau, a IMdentite du reseau d'acces utilise, lis sont egalement lies a 

25 diff6rents risques associes au materiel ou aux logiciels utilises que I'operateur et/ou 
le fournisseur d'applications et/ou I'utilisateur de I'equipement mobile desirent 
prendre en compte. 

La verification du cryptogramme peut s'effectuer lors du premier ddmanrage ou lors 
de la premiere utilisation d'une application ou d chaque demarrage de celle-ci. 
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Selon une variante, elle peut etre executee period iquement & un rythme donne 
selon des instructions provenant du serveurde controle. 

Lors d'un chargement d'une application dans un equipement mobile, le 
cryptogramnne attache accompagnant I'application inclut eh general une empreinte 
de I'application elle-meme, c'est a dire un bloc de donnees calcule a partir du code 
de I'application a I'aide d'une fonction mathematique unidirectionnelle de hachage. 

Lorsque le module d'abonne verifie la validity du cryptogramme, il identifie aussi, de 
maniere indirecte, l'equipement mobile et s'assure que les donnees viennent 
effectivement du serveur de controle. Autrement dit, par ce cryptogramme, le 
serveur de. controle donne implicitement I'assurance au module d'abonne que le 
type et la version de logiciel de l'equipement mobile ont ete pris en compte, que le 
chargement de I'application a 6t6 controle et que I'application est authentique. Selon 
des instructions pr6alablement regues, le module d'abonne decidera d'autoriser ou 
de refuser des requites ou des commandos venant de I'application. 

L'equipement mobile joue un role de relais dans cette 6tape de verification en 
^tablissant un dialogue quasi direct entre le module d'abonn6 et le serveur de 
controle. Ainsi la securite des messages echanges est assume de bout en bout 
entre le serveur de controle et le module d'abonne via I'environnement d'execution 
des applications de l'equipement mobile. Celui-ci ne peut done pas "tricher" ou 
transformer les donnees vis-d-vis du module d'abonne. 

La presente invention concerne egalement un module de s§curit£ comprenant des 
ressources destinees d §tre localement accedees par au moins une application 
installee dans un equipement relie a un reseau, ledit equipement comprenant des 
moyens de lecture et de transmission de donnees comprenant au moins I'identifiant 
de l'equipement et I'identifiant du module de securite, ledit module est caracterise 
en ce qui I comprend des moyens de reception, de stockage et d'analyse d'un 
cryptogramme contenant entre autre donnees une empreinte de ladite application et 
des instructions, des moyens de verification de ladite application et des moyens 
d'extraction et d'execution des instructions contenues dans le cryptogramme liberant 
ou bloquant certaines ressources selon le r6sultat de la verification de I'application. 
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Ce module de securite est utilise par exemple comme module d'abonn£ ou carte 
SIM connecte a un equipement mobile. 

L'invention sera mieux comprise grace a la description detaillee qui va suivre et qui 
se refere aux figures annexees donn6es A titre d'exemple nullement limitatif, d 
5 savoir: 

- La figure 1a illustre un schema bloc montrant le processus d'installation d'une 
application selon un premier mode de realisation ou le cryptogramme est delivre via 
I'environnement d'execution d'applications. 

- La figure 1 b illustre le processus de verification du cryptogramme selon le mode de 
10 la figure 1a. 

- La figure 1c illustre le processus de I'execution de ('application utilisant les 
ressources du module d'abonn£ selon le mode de la figure 1a. 

- La figure 2a illustre un schema bloc montrant le processus d'installation d'une 
application selon un second mode ou I'application seule est telechargee. 

15 - La figure 2b illustre le processus de verification ou I'application sollicite un 
cryptogramme aupres du serveur de controls selon le mode de la figure 2a. 

- La figure 2c illustre le processus de I'execution de I'application utilisant les 
ressources du module d'abonng selon le mode de la figure 2a. 

- La figure 3a illustre un schema bloc montrant le processus d'installation d'une 
20 application selon un troisieme mode ou I'application seule est telechargee. 

La figure 3b illustre le processus de verification ou I'application sollicite un 
cryptogramme et une empreinte de I'application aupres du serveur de oontrole selon 
le mode de la figure 3a. 

La figure 3c illustre le processus de I'execution de I'application utilisant les 
25 ressources du module d'abonne selon le mode de la figure 3a. 



- La figure 4 illustre la structure d'un exemple de cryptogramme. 
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Les schemas blocs des figures 1a, 1b, 1c, 2a, 2b f 2c, 3a ( 3b, 3c montrent un 
ensemble equipement mobile (CB) module d'abonne (SIM) contenant des 
ressources (RES) relie via un reseau mobile (NET) § un serveur de contrdle (CSE) 
administrd par un operateur. Ce serveur (CSE) est connects a un ou plusieurs 
fournisseurs d 'applications (FA). 

L'equipement mobile (CB) inclut une ou plusieurs applications (APP) logicielles 
fonctlonnant dans un environnement d'execution (AEE). Ces applications (APP) 
proviennent, soit du fournisseur duplications (FA) associe au serveur de contrdle 
(CSE) de I'operateur, soit, elles peuvent etre programmees d'origine par le fabricant 
de l'equipement mobile (CB). Dans ce dernier cas, il est parfois necessaire de 
telecharger des mises a jour qui sont 6galement verifiees par le module d'abonne 
(SIM). 

Selon le premier mode de realisation illustre par les figures 1a, 1b, 1c, le 
cryptogramme (CRY) d'une application (APP) est delivre au module d'abonn6 (SIM) 
via I'environnement d'execution duplications (AEE) lors du processus d'installation 
de Tapplication (APP). 

La figure 1a illustre le processus ^installation ou l'equipement mobile (CB) transmet 
d'abord des donnees servant d ('Identification (ID) du module d'abonne (SIM) que le 
serveur de controle (CSE) verifie. Cette identification (ID) est effectuee a partir de 
ridentifiant (IMSI) du module d'abonne (SIM) et de I'identifiant (IMEISV) unique de 
l'6quipement mobile (CB). Une application (APP) est ensuite t6lechargee depuis le 
serveur (CSE) accompagnee d'un cryptogramme (CRY) qui sera transmis vers le 
module d'abonne (SIM) via Tenvironnement d^xecution (AEE) pour verification 
comme illustre dans la figure 1 b. 

II est a noter que le fournisseur (FA) est considere comme digne de confiance par 
I'operateur, c'est-a-dire que les applications (APP) sont hornologuees et 
fonctionnent sans causer un quelconque prejudice a Tutilisateur et/ou a I'operateur. 

La methode selon I'invention s'applique a plusieurs formes duplications (APP) 
ex^cutees dans difFerents types d'environnement d'ex6cution (AEE). Par example, 
de nombreux telephones mobiles possedent des fonctionnalrtes issues 
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d'applications Java qui sont executees par une machine virtuelle (VM) Java servant 
de processeur et d'environnement. La description ci-aprds se base sur I'exemple 
d'applications Java. Bien entendu, d'autres environnements ou systemes 
d'explortations tels que Symbian OS, Windows, Palm OS, Linux etc. peuvent etre 
5 utilises comme support d'applications. 

Lors de son execution, voir figure 1c, une application Java sollicite le module 
d'abonn6 (SIM), elle en informe I'environnement d'execution (AEE) en lui adressant 
des requetes ou commandes (CMD). L'environnement d'execution (AEE) calcule 
I'empreinte (FIN2) de I'applicatlon (APP) et I'envoie au module d'abonne (SIM). Le 

10 cryptogramme (CRY) qui a ete genere par le serveur de contrdle (CSE) puis charge 
dans rsquipement mobile (CB) avec 1'application (APP) (ou separement), est stocke 
dans le module d'abonne (SIM). Ce dernier verifie d'abord qu'il possede 
effective ment les donn6es n6cessalres lui permettant de decider s'il doit r6 pond re a 
des requetes ou commandes (CMD) de ['application (APP). Ces donn6es, faisant 

15 office de droits charges d partir du serveur de contrdle (CSE) lors du chargement de 
rapplication (APP), permettent de controler le fonctionnement de rapplication (APP). 
En cas d'absence de ces droits, rapplication (APP) ne pourra utiliser les ressources 
(RES) (donnees ou fonctions) du module d'abonne (SIM). 

Dans le cas ou ces droits sont presents, le module d'abonne (SIM) verifie 
20 Tempreinte (FIN1) issue du cryptogramme (CRY) stocke en la comparant avec 
I'empreinte (FIN2) associ€e d rapplication (APP) et foumie par Tenvlronnement 
d'application (AEE). Ce cryptogramme (CRY) peut se constituer sous la forme d'un 
bloc encrypts par une cl6 privee du type RSA (Rivest, Shamir, Adelman). Ce bloc 
reprdsentd par la figure 4 contient par exemple, entre autres donnees, I'identifiant 
25 IMSI (ID_SIM) du module (SIM) d'abonne, Pidentifiarit IMEISV (ID_CB) de 
l'6quipement mobile (CB), un Identificateur (ID^APP) de rapplication, I'empreinte 
(FIN1) de ('application (APP), des identificateurs SIM (RESJD) des ressources 
(RES) et des instructions (INSURES) de blocage/libdration des ressources SIM. 
Cette cle priv6e ne serait connue que du serveur de contrdle (CSE), alors que sa 
30 partie publique serait connue du module d'abonn£ (SIM). L'avantage de ('utilisation 
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de cl6s asym6triques reside en ce que la cl6 servant d cr6er des cryptogrammes ne 
se trouve pas a I'exterieur du serveur de controle (CSE). 

Bien entendu, d'autres algorithmes a cles asymetriques tels que par exemple DSA 
(Digital Signature Algorithm), et ECC (Elliptic Curve Cryptography) peuvent 
constituer des alternatives a RSA 

L'usage d'algorithme a cles symetriques peut etre prefere pour des raisons de 
simplicity, de rapidite des v6rifications ou de coQts de fabrication et de mise en 
oeuvre plus faibles. Dans ce cas, la cle serait connue du serveur (CSE) et du 
module d'abonn§ (SIM), par exemple un algorithme IDEA (International Data 
Encryption Algorithm) pourrait etre utilise pour signer le bloc (IMSI, IMEISV, 
identificateur de Implication, empreinte de Tapplication, identrficateurs des 
ressources SIM, instructions de blocage/liberation des ressources SIM). Comme 
alternative A Palgorithme IDEA, des algorithmes tels que, par exemple, TDES (Triple 
Data Encryption Standard) et AES (Advanced Encryption Standard) peuvent aussi 
etre utilises. 

Dans ces deux variantes a cles asymetriques et symetriques, le module d'abonne 
(SIM) verifie la concordance des differents champs apparaissant dans le 
cryptogramme (CRY), notamment il controle les identificateurs d'applications 
(ID_APP) et les empreintes d'applications (FIN1) qui sont autoris6es ou non A 
utiliser ses ressources (RES) (donnees ou fonctions). 

Dans une variante, le cryptogramme (CRY) peut inclure un compteur servant d 
empecher le double usage d'un meme cryptogramme adresse au module d'abonne 
(SIM) (replay attack). En effet deux applications du meme type peuvent porter le 
m§me identificateur et avoir la meme empreinte (FIN1). Dans ce cas, le module 
d'abonne (SIM) controlera aussi la valeur de ce compteur par comparaison avec 
celle d f un compteur de reference stocke et regulierement mis a jour. 

Une variante au compteur est d'utiliser un alea (nombre aleatoire) genere par le 
module d'abonnd (SIM). Cet alea est transmis avec les donnees envoyees au 
serveur de controle (CSE). Ce dernier renvoie cet alea dans le message de reponse 
et le module d'abonne (SIM) peut verifier qu'il s'agrt bien d'un nouveau message. 
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Plus g6n6ralement, afin d'6viter tout risque d'usage d'un ancien cryptogramme 
(CRY), cette derniere comprend une variable predict! ble par le module d'abonne 
(SIM), soit un compteur ou un alGa. 

Dans une autre variante le cryptogramme (CRY) genera a Paide d'une cl6 du type 
5 RSA ou IDEA peut etre remplacee par un bloc genere avec une cl6 partagee HMAC 
(Keyed-Hashing for Message Authentication) d partir de I'ensemble (IMSI, IMEISV, 
identificateur de I'application , empreinte de ('application, identificateurs des 
ressources SIM, instructions de blocage/lib6ration des ressources SIM). HMAC est 
un mecanisme pour I'a identification de messages par 1'utilisation de fonctions de 
10 hachage cryptographiques telles que MD5 (Message Digest) ou SHA-1 (Secure 
Hash Algorithm), en combinaison avec une cle partag6e. 

Cette cle presente a la fois dans le serveur de controle (CSE) et dans le module 
d'abonne (SIM) peut etre chargee lors de la personnalisation du module d'abonne 
(SIM) ou lors de ('installation de certaines ressources (RES) dans le module 
15 d'abonne (SIM). Selon les options, a chaque ressource (RES) ou groupe de 
ressources du module d'abonn6 (SIM) peut £tre associ€e une cl6 diff6rente, ou 
bien, la c!6 peut etre globale pour I'ensemble des ressources (RES) et unique pour 
un module d'abonng (SIM) donne. 

Le cryptogramme (CRY) permet ainsi au module d'abonne (SIM) de connaTtre la ou 
20 les ressources CRES) pouvant etre Iib6r6es ou bloquees dans le module d'abonne 
(SIM) pour I'equipement mobile (CB) correspondant. 

Les deux empreintes utilisees (FIN1, respectivement FIN2) sont des Elements 
determinants car elles constituent un moyen de contrdle cryptographique de 
I'application (APP) par I'equipement mobile (CB) et par le module d'abonne (SIM). 
25 Un tel controle est necessaire afin d'empecher qu'une application tierce s'authentlfie 
avec un cryptogramme (CRY) donne. En effet, si le cryptogramme A authentifie 
I'application A aupres du module d'abonne A dans un 6quipement mobile A, il faut 
6viter qu'une autre application B s'authentifie indQment avec ce meme 
cryptogramme A aupres du module d'abonne A dans i'equipement mobile A. 
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Selon une variante, I'empreinte de I'application (FIN1) incluse dans le cryptogram me 
(CRY) reste confidentielle de bout en bout entre le serveur de controle (CSE) et le 
module d'abonn§ (SIM). Pour ce faine I'empreinte (FIN1) est encrypt6e par le 
serveur de controle (CSE) et decryptee par le module d'abonne (SIM). De plus, 
5 ['application (APP) peut etre personnalisee pour un chargement donn6 de manidre a 
ce que I'empreinte (FIN1) induse dans le cryptogramme (CRY) et I'empreinte (FIN2) 
de I'application (APP) calculee par I'environnement d'ex6cution (AEE) restent 
identiques mais dependent de I'identite de Tequipement mobile (CB). Une telle 
mesure est n6cessaire si Ton desire empecher qu'une application tierce s'authentifie 

1 0 avec une empreinte donnee dans un autre environnement d'execution d'applications 
(AEE) dont ('interface avec le module d'abonne (SIM) serait compromise. En effet, si 
I'empreinte A authentifie I'application A aupres du module d'abonne A dans un 
equipement mobile A, il faut eviter qu'une autre application B s'authentifie indument 
avec cette meme empreinte A aupres du module d'abonn6 B dans I'gquipement 

1 5 mobile B. 

Selon une autre variante, chaque application (du type Java) est accompagn6e de 
deux cryptogrammes: un cryptogramme Java destine a la machine virtuelle (VM) et 
un cryptogramme (CRY) destine au module d'abonn6 (SIM). Ces deux 
cryptogrammes comprennent entre autre la meme empreinte d'application (ici 

20 appeiee FIN2) qui est celle du code de I'application Java. Alnsl, lorsque le module 
d'abonne (SIM) doit verifier le cryptogramme (CRY) d'une application, il attend de la 
machine virtuelle (VM) I'empreinte (FIN2) associfie a I'application (APP) en question 
qu'elle aura forcement calculee auparavant. L'empreinte de Tapplication est 
transmise par T6quipement mobile (CB) au module d'abonne (SIM). Cette empreinte 

25 ne provient pas du serveur de controle, elle est calculee par I'environnement 
d'ex6cution d'applications (AEE) de I'equipement mobile (CB) apres le 
tel§chargement de I'application (APP). Par centre, l'6quipement mobile (CB) 
transmet le cryptogramme (CRY) prealablement charge en sus de I'application 
depuis le serveur de controle au module d'abonne. Ainsi, ce dernier peut verifier 

30 I'empreinte regue par comparaison. L'equipement mobile (CB) ne peut pas tricher 
tant qu'il ne connaft pas I'empreinte attendue par le module d'abonne (SIM); le cas 
echeant, cela n6cessiterait de rendre la fonction de calcul de I'empreinte, 



WO 2005/053263 



-15- 



PCT/EP2004/0531 16 



habftuellement une fonctlon de hachage, r6verslb!e ou de trouver une autre 
empreinte dormant le meme cryptogramme (CRY) ce qui estquasiment impossible. 

La figure 1b montre le processus de verification du cryptogramme (CRY) qui peut 
s'effectuer soit r6guli6rement, par exemple avant chaque sollicitation de I'application 
5 (APP) concemee, soit, de preference, une seule fois avant son installation ou avant 
sa premiere utilisation. Si le cryptogramme (CRY) est valide, le module d'abonne 
(SIM) transmet un message d'acceptation (OK) a I'environnement d'execution (AEE). 
L'application (APP) peut alors adresser ses requetes ou commandes (CMD) au 
module d'abonne (SIM) via I'environnement d'execution (AEE) et utiliser les 
10 ressources (RES) du module d'abonne (SIM). Ce dernier accepte les commandes 
(CMD) en transmettant les reponses (RSP) adequates a I'application (APP) via 
l'environnement d'execution (AEE), voir figure 1c. 

Dans le cas d'un cryptogramme (CRY) non valide, le module d'abonne (SIM) 
transmet un message de refus (NOK) & I'environnement d'execution (AEE). Dans un 
15 tel cas I'environnement d'execution (AEE) peut soit annuler le processus 
d'installation de I'application (APP), soit I'application (APP) est installee et ses 
requetes ou ses commandes (CMD) adressees au module d'abonne (SIM) via 
renvironnement d'execution (AEE) resteront sans reponse (RSP) et les ressources 
(RES) du module d'abonnd (SIM) ne pourront etre utilisees. 

20 Dans les deux cas d'acceptation et de refus (OK et NOK) I'environnement 
d'execution d'application (AEE) peut relayer la reponse au serveur de controle 
(CSE). Le module d'abonne peut ainsi indirectement renvoyer une confirmation (CF) 
de reception du cryptogramme (CRY) au serveur de controle (CSE) et permettre un 
controle de bout en bout de I'operation, voir figure 1b. La confirmation (CF) 

25 comprend au moins un code de succes ou d'erreur de I'operation ainsi qu'un 
compteur servant a la protection contre des attaques par repetition. Ce message 
permet aussi au serveur de controle (CSE) de tenir d Jour le compteur associg au 
module d'abonne (SIM). 
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Selon le second mode de realisation illustre par les figures 2a, 2b, 2c, ['application 
(APP) est tel£chargee seule, apres identification (ID) de I'equipement mobile (CB), 
sans cryptogramme (CRY), voir figure 2a. 

Lors du processus de verification, figure 2b, I'appllcation (APP) solliclte, tors de son 
5 lancement par I'utilisateur, un cryptogramme (CRY) comprenant les droits 
d'utilisation de ressources (RES) pour ladite application. Ce cryptogramme (CRY) 
est telecharge, depuis le serveur (CSE) de controle, directement par ("application 
(APP) qui le transmet au module d'abonne (SIM) via I'environnement d'execution 
(AEE). Le module d'abonne (SIM) transmet une confirmation (CF) de reception du 
10 cryptogramme (CRY) au serveur (CSE), par le biais de ('application (APP) et non par 
le biais de I'environnement d'execution (AEE) comme dans le cas du premier mode 
de realisation. Dans ce mode, I'environnement d'execution (AEE) ne joue qu'un role 
de relais entre I'application (APP) et le module d'abonnd (SIM). 

Le processus d'execution de I'appllcation (APP) aprds verification du cryptogramme 
15 (CRY), voir figure 2c, se deroule de la meme maniere que dans le premier mode 
illustre par la figure 1c et d6crit plus haut. 

Les figures 3a, 3b, 3c montrent une troisieme variante ou I'application APP est 
telechargee seule, apres identification (ID) de I'equipement mobile (CB), depuis le 
serveur de controle (CSE) ou depuis un serveur intermediaire de telechargement 

20 d'applications (APP) voir figure 3a. Lors du processus de verification (figure 3b), 
I'application charge le cryptogramme (CRY) et I'empreinte (FIN2) directement a 
partir du serveur (CSE) ou depuis un serveur intermediaire de telechargement 
d'applications (APP). Dans ce cas, a la difference des deux variantes precedentes, 
I'environnement d'application (AEE) ne calcule plus I'empreinte (FIN2) qui est 

25 calculee par une unite externe soit par le serveur de controle CSE, sort par un 
serveur intermediaire de telechargement d'applications (APP). 

Le processus d'execution de I'application (APP) apres verification du cryptogramme 
(CRY), voir figure 3c, se deroule de la m§me maniere que dans les deux modes 
precedents illustres par les figures 1c et 2c. 
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Ce troisieme mode de r6alisation peut Stre prefere car son avantage est de ne 
demander aucune modification de I'environnement d'ex6cution (AEE) tel qu'il est 
defini actuellement pour les applications Java installees dans les telephones 
mobiles, c'est-a-dire qu'une modification des nonmes existantes n'est pas 
5 n6cessaire. 

De plus, la contrainte de la premiere variante voulant que les deux cryptogrammes 
utilisent la meme empreinte tombe etant donne que les processus de verification du 
cryptogramme (CRY) et celui de Installation de I'application sont totalement 
ind6pendants. 

10 Afin de personnaliser les empreintes calculees sur les applications, une possibilit6 
consiste £ ajouter au code de I'application, avant son chargement dans I'equipement 
mobile, une donnee differente pour chaque 6quipement mobile. Ainsi, lorsque 
I'empreinte est calculee par I'environnement d'application de l'6quipement mobile, 
cette empreinte est unique et ne peut servir d un autre gquipement mobile. Le 

15 cryptogramme va bien entendu etre calcul6 par le serveur de controle sur la base 
des donn£es d'origine de Tapplication et de cette donn€e unique. 

Dans une variante de Tinvention, I'equipement mobile peut etre remplace par un 
equipement non mobile tel qu'un d6codeur de television a peage ou un ordinateur. 
Des applications peuvent Stre t6lechargees dans I'equipement a partir d'un serveur 
20 via un reseau de telecommunications. Un cryptogramme assoclg d I'application est 
stocks dans le module de securite et verifie lors de la mise en service ou lors de 
chaque d6marrage d'une application. Le resultat de cette v6rification conditionne le 
fonctionnement de I'application en liberant ou en bloquant des ressources dans le 
module de s6curit6. 



25 
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REVENDICATIONS 

1. Methods d'authentification d'au moins une application (APP) fonctionnant 
dans un equipernent (CB) connecte par un reseau (NET) a un serveur de contrdle 
(CSE), ledit equipernent (CB) etant localement connecte a un module de s6curit6 
(SIM), ladite application (APP) est chargee et/ou executee au moyen d'un 
environnement d'ex6cution duplications (AEE) de l'6quipement (CB) et utilise des 
ressources (RES) stock6es dans le module de s£curit€ (SIM), comprenant les 
6tapes prelimlnaires suivantes: 

- reception de donnees comprenant au moins i'identrflant (IMEISV) de 
I'equipement (CB) et I'ldentifiant (IMSI) du module de s6curit6 (SIM), via le 
reseau (NET), par le serveur de contrdle (CSE) 

- analyse et verification par le serveur de contrdle (CSE) desdrtes donnees, 
g6n6ration d'un cryptogramme (CRY) comprenant une empreinte (FIN1) de 
('application (APP), des donnees identifiant I'equipement (CB) et le module de 
securite (SIM) et des instructions (INSURES) destinees audit module, 
transmission dudit cryptogramme (CRY), via le reseau (NET) et i'equipement 
(CB), au module de security (SIM), 

verification de I'application (APP) en comparant I'empreinte (FIN1) extraite du 
cryptogramme (CRY) regu avec une empreinte (FIN2) d6terminee par le 
module de s6curit6 (SIM), 
ladite m6thode est caracterisee en ce que, lors de ('initialisation et/ou de I'activation 
de ('application (APP), le module de securite (SIM) execute les instructions 
(INSURES) extraites du cryptogramme (CRY) et libfere, respectivement bloque 
I'acces a certaines ressources (RES) dudit module de securite (SIM) en fbnction du 
rSsuttat de la verification propre d cette application (APP) effectuee prealablement. 

2. Methode seion la revendication 1 caracterisee en ce que I'equipement est un 
equipernent mobile (CB) de telephonie mobile. 

3. Methode selon la revendication 1 caracterisee en ce que le reseau (NET) est 
un reseau mobile du type GSM ou GPRS ou UMTS. 
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4. Mgthode selon la revendication 1 ou 2, caracterisee en ce que le module de 
sgcurite (SIM) est un module d'abonne insere dans I'equipement mobile (CB) de 
t6l6phonie mobile de type carte SIM. 

5. Mgthode selon la revendication 1 ou 4 caracterisee en ce que Identification 
(ID) de I'ensemble equipement mobile (CB) / module d'abonne (SIM) est effectuge a 
partir de ridentifiant (IMEISV) de I'equipement mobile (CB) et de I'identifiant (IMSI) 
du module d'abonne (SIM) propre a un abonne au reseau (NET). 

6. Methode selon la revendication 1 caracterisee en ce que les instructions 
incluses dans le cryptogramme (CRY) regu par le module de s6curite (SIM) 
conditionnent Tutilisation des applications (APP) selon des entires preetablis par 
I'operateur et/ou le fournisseur d'applications (FA) et/ou I'utilisateur de I'equipement. 

7. M6thode selon la revendication 6 caracterisee en ce que les criteres 
d£finissent des limites d'utilisation d'une application (APP) selon des risques 
associes au logiciel de ladite application (APP) ou au materiel de I'equipement (CB) 
que I'operateur desire prendre en compte. 

8. Methode selon la revendication 1 caracterisee en ce que la verification de 
I'application (APP) avec le cryptogramme (CRY) s'effectue lors du premier 
demarrage ou lors de la premiere utilisation de ladite application (APP). 

9. Methode selon la revendication 1 caracterisee en ce que la verification de 
Papplication (APP) avec le cryptogramme (CRY) s'effectue periodiquement a un 
rythme donn6 selon des instructions provenant du serveur de controle (CSE). 

10. Methode selon la revendication 1 caracterisee en ce que la verification de 
I'application (APP) avec le cryptogramme (CRY) s'effectue lors de chaque 
demarrage de ladite application (APP) sur I'equipement (CB). 

11. Methode selon la revendication 1 caracterisee en ce que le cryptogramme 
(CRY) est genere a I'aide d'une cle d'encryption asymetrique ou symetrique a partir 
d'un ensemble de donndes contenant, entre autres donn£es, ridentifiant (IMEISV) 
de I'equipement (CB), ridentifiant (IMSI) du module de s6curite (SIM), un 
identrficateur de I'application (APP), I'empreinte (FIN1) de I'application (APP) 
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calculee avec une fonction unidirectionnelle de hachage, des identrficateurs 
(RESJD) d©s ressources du module de securite (SIM) et des instructions 
(INSURES) de blocage/liberation des ressources (RES) du module de securite 
(SIM). 

12. Mdthode selon la revendication 11 caracterisee en ce que le cryptogramme 
(CRY) comprend une variable predictible par le module de securite (SIM) dvltant le 
double usage d'un meme cryptogramme (CRY), la valeur de ladite variable 6tant 
controlee par le module de securite (SIM) par comparaison avec celle d'une valeur 
de reference stock£e dans ledit module et r6gulierement mise a jour. 

13. M6thode selon la revendication 1 caracterisee en ce que le module de 
securite (SIM) transmet au serveur de controle (CSE), via I'equipement (CB) et le 
reseau (NET), un message de confirmation (CF) lorsque ledit module de securite 
(SIM) a accepte ou refuse un cryptogramme (CRY) d'une application (APP). 

14. M6thode selon la revendication 1 caracterisee en ce que le cryptogramme 
(CRY) est transmis au module de securite (SIM) en meme temps que Papplication 
(APP) est charg6e dans rdquipement (CB) via I'envinonnement d'execution des 
applications (AEE). 

15. Methode selon la revendication 1 caracterisee en ce que ('application (APP), 
une fois chargee dans I'equipement (CB) depuls le serveur (CSE) de controle via le 
r6seau (NET), sollicite un cryptogramme (CRY) au serveur (CSE) lors de son 
initialisation et transmet ledit cryptogramme (CRY) au module de s6curite (SIM), le 
message de confirmation (CF) d'acceptation ou de refus du cryptogramme (CRY) 
etant transmis par le module de securite (SIM) au serveur via Tapplication (APP). 

16. Methode selon la revendication 1 , caracterisee en ce que I'equipement est un 
decodeur de television £ p6age ou un ordinateur auquel est connecte le module de 
securite. 

17. Module de securite comprenant des ressources (RES) destinees a etre 
localement acc6dees par au moins une application (APP) installee dans un 
6quipement (CB) relte a un r6seau (NET), ledit equipement (CB) comprenant des 
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moyens de lecture et de transmission de donnees comprenant au moins I'identifiant 
(IMEISV) de I'equipement (CB) et I'identifiant (IMS!) du module de s6curit6 (SIM), 
ledit module est caracterise en ce qu'il comprend des moyens de reception, de 
stockage et d'analyse d'un cryptogramme (CRY) contenant entre autre donndes une 
empreinte (FIN1) de ladite application (APP) et des instructions (INSJRES), des 
moyens de verification de ladite application (APP) et des moyens d'extraction et 
d'execution des instructions (INSURES) oontenues dans Ie cryptogramme (CRY) 
liberant ou bloquant certaines ressources (RES) selon le resultat de la verification 
de I'application (APP). 

18. Module de security selon la revendication 17, caracterise en ce qu'il est du 
type "module d'abonn6" ou "carte SIM" destin6 & £tre reII6 d un equipement mobile. 
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